home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 73 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.5 KB

  1. From: bs@research.att.com
  2. Message-ID: <199601191512.IAA09192@tijeras.scd.ucar.EDU>
  3. X-Original-Date: Fri, 19 Jan 96 10:11 EST
  4. Path: in1.uu.net!bounce-back
  5. Date: 19 Jan 96 17:17:09 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Organization: -
  8. Newsgroups: comp.std.c++
  9. Subject: Re: STL still in standard
  10. References: <4dgrb4$a2e@engnews1.Eng.Sun.COM> <4dd7on$djk@rc1.vub.ac.be>
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMP/S2OEDnX0m9pzZAQHGyAF/W4nvd17yEop7GCHRSjxQFl0XlwYi7goK
  13.     UhkUvEmWed5AizUedAJO2pU7IicWY+Jc
  14.     =Lamv
  15.  
  16. aishdas@haven.ios.com (Micha Berger)
  17.  
  18.  > Steve Clamage (clamage@Eng.Sun.COM), the  Chair of X3J16, C++ Committee
  19.  > writes::
  20.  > : The C++ Committee has been unanimous (or nearly so) in its acceptance
  21.  > : of STL. I do not believe there is any chance it will be dropped.
  22.  
  23. I agree. The STL is here to stay, and I for one am is glad that it is.
  24.  
  25.  > I don't like STL because it represents an abandonment of one of C++'s
  26.  > strengths, the tools for implementing an object oriented design.
  27.  
  28. Preferring one tool for another for a particular task is not abandonment
  29. of other tools in a toolset. It is the proper way to use a tool set.
  30.  
  31. An analogy: I'm not abandoning my fork because I prefer to use a spoon to
  32. eat my soup. You can design a contraption that can be used as a spoon, a
  33. fork, and a knife. That way, you can have a single tool rather than a
  34. tool set. However, that ``sporkn'' is not quite as good a fork as a fork,
  35. not quite as good a spoon as a spoon, ...
  36.  
  37.  > STL just isn't OO. It's the creation of algorythms that are not connected
  38.  > to the data they act upon. That doesn't make STL inherently wrong, but it
  39.  > does seem out of place in light of the number of design decisions made
  40.  > to enable OO.
  41.  
  42. In my opinion, templates is a better mechanism for creating efficient
  43. type-safe containers than derivation. You can build a conventional OO
  44. container and its associated operations on top of the STL without loss
  45. of efficiency or generality. The opposite is not the case for any
  46. inheritance-based library I have seen. For that reason alone, the STL
  47. is a better choice as a *standard* library.
  48.  
  49. In general, please remember that OOP is not the only effective form
  50. of programming. Use of inheritance often leads to the most extensible,
  51. efficient, and general systems, but not always. Associating operations
  52. directly with a class as members often gives the greatest notational
  53. convenience, efficiency, and maintianability, but not always.
  54.  
  55. STL is an example of a library where generality, elegance, and efficiency
  56. were best achieved through other means. Had the containers been provided
  57. without algorithms, programmers would have had to write their own (imagine
  58. C-style strings without strlen(), stdcpy(), ...). Had the algorithms not
  59. been generic, they would have had to be replicated (undoubtedly with many
  60. minor an annoying variations), or we would have had to invent a set of
  61. container convertion mechanisms. Had the algorithms been less general
  62. in their interfaces, they would not have met the needs of experts.
  63.  
  64. Where needed, we regain the classical OO benefits by using objects and
  65. pointers to polymorphic objects as elements of containers, and by using
  66. the containers and algorithms in the implementation of more traditional
  67. hierarchies.
  68.  
  69. C++ is a multi-paradigm language (see D&E); the aim is to utilize the
  70. various styles where appropriate.
  71.  
  72.     - Bjarne
  73.  
  74.  
  75. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  76.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  77.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  78.